The present invention relates generally to the field of object-oriented programming. More specifically, to object oriented frameworks.
Object oriented programming represents a body of programming in which programmers define not only the data type of a data structure, but also the operations (functions) that can be applied to those data structure. In this way, the data structure becomes an object that includes both data and functions. In addition, programmers can create relationships between one object and another and objects can inherit characteristics from other objects.
One of the principal advantages of object-oriented programming techniques over procedural programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify. Programmers perform object-oriented programming far more conveniently in an object-oriented programming language (OOPL). Java, C++ and Smalltalk are three of the more famous languages, and there are also object-oriented versions of Pascal.
Most software systems have some type of graphical user interface (UI). In traditional software prototyping and development, the software designer builds the interface with direct coupling to one or more dispersed business rules. A general overview is illustrated in FIG. 1. As shown, UI 100 comprises a number of “widgets,” (or “controls”) 102, which can be text boxes, combo boxes, buttons, etc. When the state of a UI widget changes, or causes an event, the corresponding code and business rules are invoked to handle the change or event so as to accomplish the functions of the software application. The code and rules may access database 106 to retrieve information, perform calculations, etc. This merging of user-interface and business logic is even more common in the systems that are most famous for rapid construction. This style of system construction loses much of the benefit of object technology, especially in terms of the management of program complexity and the ease with which new capabilities can be added to an application as requirements change.
Because user interfaces are generally coded with the programmer having to think in terms of the management of events and states, the process becomes complicated quickly. Hence, the interface often takes more effort and code than the business logic. The complexity increases even more for web-based applications. HTTP/HTML is fundamentally a low-level building block, too low to construct easily maintainable systems. A developer needs to be concerned about far too many technical details, while working with browsers that were not designed to support the demands of contemporary user interfaces. Improvements have been made incrementally, but good programming abstractions have not been the result. Building web interfaces today involves a large mismatch between what the web applications need to do and what HTTP/HTML expresses easily.
Many times, in a design process, early development of a small-scale prototype is used to test certain key features of the design. Prototypes are extremely useful in important ways to reduce risk on software development projects. For instance, good prototypes can serve as the foundation of the eventual delivered system. Also, when a prototype is available early, the problem of miscommunication between developers and users, analysts and executives is greatly reduced.
The difficulty of programming user interfaces, however, normally inhibits the rapid development of “foundational” prototypes, i.e. prototypes that serve as the foundation of the eventual delivered system. Thus, if the complexity in the UI code could be reduced, they could be built quickly, which would then make it possible to provide prototypes earlier in the design process.
There are also other advantages to reducing the complexity of the UI code. Often, the complexity in an application is in the presentation layer. If the size of that portion of the code is reduced dramatically, the maintainability of the delivered software is improved. Software maintenance is often among the greatest costs in the software life cycle. Therefore, if the complexity of presentation layer software can reduced so that it can be built rapidly, software-project return on investment (ROI) can be dramatically improved.
What is needed is a framework and allied tools that enable a software developer to easily create software systems that have arbitrarily complex UIs, where the UI can be coded quickly and with reduced complexity. Such a framework and tools would enable rapid foundational prototyping.